feat: DoH3 resolver #166
feat: DoH3 resolver #166
Conversation
|
Please correct me if I'm wrong, but isn't DoH3/DoQ is a pretty bad idea for anti-censorship since they specifically use port 8853 and would not masquerade as well with HTTPS traffic on 443? |
As far as I am aware, DoH3 and DoQ are not the same thing. DoQ relies on Quic as a transport-level protocol, which is built on top of UDP and uses UDP port 853, while DoH3 relies on HTTP, which happens to be HTTP/3, which in turn uses Quic as transport. |
|
OMG i for got to merge it. i still have it in my local i will resolve and merge it to the main now |
|
Ok, I pushed my local copy to the fork's branch in case you need it. |
|
It's done but i actually had to overwrite the conflicted files because there was too much conflict with current main branch. I'm so sorry about this. |
Ledorub
force-pushed
the
feature-doh3-resolver
branch
from
e29f02d
to
31930ca
Compare
Ledorub
force-pushed
the
feature-doh3-resolver
branch
from
31930ca
to
4374701
Compare
With recent changes made in #161 and refactoring that followed in #163, it is now easy to add new resolvers.
This PR adds an experimental DNS-over-HTTP/3 resolver on top of the #163. Its implementation depends on quic-go module, as Go's STL is not ready for HTTP/3 yet.
To use the resolver one should replace the following line of code:
https://github.com/Ledorub/SpoofDPI/blob/e29f02d596df8f7355f8280c5622aa508ce89159/dns/dns.go#L38
with:
I used it for a day, and for me it was less stable and performant than the default DoH resolver. Some lookups take 100+ ms to resolve, some fails with timeout. It is not clear, what causes the issues. Is it a calling code, HTTP client & transport configuration or the
quic-gomodule.